Typical existing painting systems utilize Wait/Release commands with explicitly specified conveyor position or location statements. This may be adaptable to helping robots get back in synchronization, but not in all cases. The burden is on the end user to determine how to place and manage the instructions, making it a fairly complex operation requiring expert knowledge. Other examples of prior art include systems using interference zones, or systems using a master/slave relationship between robots (for example, coordinated motion) to keep the arms from moving near to each other. As another example, a “Conveyor Sync” algorithm is used that explicitly stops and restarts the robot coincidentally with the conveyor stop and start events, and/or varies robot speed directly proportional to conveyor speed changes.
The prior art systems have the following shortcomings:                (a) Explicit Conveyor Location Statements or Wait/Release statements do not address cases where robots stop in between the explicitly defined conveyor locations. They also place a high burden of expertise on the end user to make the systems work.        (b) Coordination Motion and other master/slave type algorithms involve more programming complexity, and may not be feasible in cases where the conveyor is controlled by an external entity.        (c) Conveyor Sync can impede paint quality in that TCP speed may not be always properly maintained relative to the object, and trigger points (i.e. where the paint gun is turned on or off relative to the object) cannot be as easily defined.        